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STATUS OF CLAIMS 

Claims 1-12 are pending and all stand rejected. 
Accordingly, the claims on Appeal are claims 1-12. 

STATUS OF AMENDMENTS 

There are no pending amendments with respect to this application. 

SUMMARY OF CLAIMED SUBJECT MATTER 

The present invention is directed to a communication system including an in- 
home network, a method of communicating in a communication system including an 
in-home network, and a remote device and an intermediate device for use in a 
communication system including an in-home network. 1 

Accordingly, as broadly recited in claim 1, a communication system (100 - 
FIG. 3) includes an in-home network (140 - FIGs. 3, 4B) and a remote device (110 — 
FIGs. 3, 4B, 5) (page 4, lines 30-32). The in-home network (100) includes a plurality 
of in-home devices (130, 150 - FIGs. 3, 4B, 5) (page 4, lines 32-35) operative to 
communicate using predetermined in-home protocols (232/252, 234/254 - FIG. 4B) 
including an in-home application protocol (234/254) (page 5, lines 12-13). At least 
one of the in-home devices is referred to as an intermediate device (130 - FIGs. 3, 
4B, 5) (page 4, lines 32-33), and it is operative to communicate with the remote 
device (110) using predetermined remote protocols (230/210- FIG. 4B; 332/334 - 
FIG. 5) including a remote application protocol (332/334 - FIG. 5) which differs from 
the in-home application protocol (234/254) (page 6, lines 16-33). The remote device 
(110) is operative to load a portable application program (238 - FIG. 4B) (page 6, 
lines 7-8) for controlling at least one of the in-home devices (150) by calling an 
Application Program Interface (API) (236 - FIG. 4B, 5) of the in-home application 

1 In the description to follow, citations to various reference numerals, figures, and corresponding text 
in the specification are provided solely to comply with Patent Office rules. It should be understood that 
these reference numerals, figures, and text are exemplary in nature, and not in anyway limiting of the 
true scope of the claims. It would therefore be improper to import anything into any of the claims simply 
on the basis of exemplary language that is provided here only under the obligation to satisfy Patent 
Office rules for maintaining an Appeal. 
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protocol (234/254); and load an API emulator (310 - FIGs. 4B) operative to provide a 
callable interface for functions of the in-home application protocol (234/254), and to 
supply this API functionality by communicating with a module (330 - FIG. 4B) in the 
intermediate device (130) using the remote protocols (page 6, lines 11-33). The 
intermediate device (130) includes: (1) an API (236) operative to provide interface 
functionality for the functions of the in-home application protocol (234/254) by 
controlling the intermediate device (130) and/or communicating with other in-home 
devices (150) according to application messages of the in-home application protocol 
(234/254) (page 5, line 32; page 7, lines 29-32; page 4, lines 24-29); and (2) the 
module (330 - FIG. 4B) for communicating between the API emulator (310) in the 
remote device (110) and the API (236) in the intermediate device (130), establishing 
a substantially transparent communication path between the portable application 
program (238) in the remote device (110) and the API (236) in the intermediate 
device (130) (page 6, lines 18-33). 

As broadly recited in claim 2, the invention further features the in-home 
protocols including a messaging protocol (232/252; 40/530 - FIGs. 1 , 2), 
hierarchically below the in-home application protocol (234/254; 20/520 - FIGs. 1, 2) 
(page 4, lines 5-17, 24-26; page 2, line 29 - page 3, line 6), and the API emulator 
(310) being operative to supply the API functionality by executing the in-home 
application protocol (234/254) in the remote device (110) and supplying the in-home 
application protocol (234/254) an interface to the messaging protocol (232/252) by 
communicating with the module (330) in the intermediate device (130) using the 
remote protocols (210/230) (page 6, lines 12-33). 

As broadly recited in claim 3, the invention further features the in-home 
application protocols (234/254) being Home Audio/Video interoperability (HAVi) 
based (page 1, lines 5-7; page 4, line 31 - page 5, line 2; page 5, lines 12-13). 

As broadly recited in claim 4, the invention further features the portable 
application program (238) being Java based (page 5, lines 14-15). 

As broadly recited in claim 5, the invention further features the remote 
protocols (230/210) being based on Internet protocols (page 4, line 31 - page 5, line 
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2; page 5, lines 10-11). 

As broadly recited in claim 6, the invention further features the API emulator 
(310) and the module (330) communicating using a remote procedure calling 
protocol (page 6, lines 24-28; page 10, lines 20-23). 

As broadly recited in claim 7, the invention further features information to be 
communicated between the API emulator (310) and the module (330) are described 
using a mark-up language (page 7, lines 24-25). 

As broadly recited in claim 8, the invention further features the remote device 
(110) being operative to load the portable application program (238) and/or API 
emulator (310) from the intermediate device (130) (page 8, lines 1 1-27). 

As broadly recited in claim 9, the invention further features the remote device 
(110) being operative to load the portable application program (238) and/or API 
emulator (310) from an in-home device (150), other than the intermediate device 
(130), via the intermediate device (130) (page 8, line 28 - page 9, line 2). 

As broadly recited in claim 10, the invention further features a remote device 
(110) for use in a communication system (100) as claimed in claim 1 (page 4, lines 
30-32). The remote device (110) is operative to load a portable application program 
(238) (page 6, lines 7-8) for controlling an in-home device (150) by calling an 
Application Program Interface (API) (236) of an in-home application protocol 
(234/254); and load an API emulator (310) operative to provide a callable interface 
for functions of the in-home application protocol (234/254), and to supply this API 
functionality by communicating with a module (330) in an intermediate device (130) 
using predetermined remote protocols (230/130; 332/334) including a remote 
application protocol (332/334) which differs from the in-home application protocol 
(234/254) (page 6, lines 1 1-33). The intermediate device (130) is on an in-home 
network (140) including a plurality of in-home devices (130, 150) operative to 
communicate using predetermined in-home protocols (232/252, 234/254) including 
the in-home application protocol (234/254) (page 5, lines 12-13; page 6, lines 16-33). 

As broadly recited in claim 11, the invention further features an intermediate 
device (130) for use in a communication system (100) as claimed in claim 1. The 
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intermediate device (130) is on an in-home network (140) including a plurality of in- 
home devices operative to communicate using predetermined in-home protocols 
(232/252, 234/254) including an in-home application protocol (234/254). The 
intermediate device (130) also is operative to communicate with a remote device 
(110) using predetermined remote protocols (230/210- FIG. 4B; 332/334 - FIG. 5) 
including a remote application protocol (332/334 - FIG. 5) which differs from the in- 
home application protocol (234/254) (page 6, lines 16-33). The intermediate device 
(130) includes: (1) an Application Program Interface (API) (236) of the in-home 
application protocol (234/254) operative to provide interface functionality for functions 
of the in-home application protocol by controlling the intermediate device (130) 
and/or communicating with other in-home devices (150) according to application 
messages of the in-home application protocol (page 5, line 32; page 7, lines 29-32; 
page 4, lines 24-29); and (2) a module (330) for communicating between an API 
emulator (310) in the remote device (110) and the API (236) in the intermediate 
device (130), establishing a substantially transparent communication path between a 
portable application program (238) in the remote device (110) and the API (236) in 
the intermediate device (130) (page 6, lines 18-33). The portable application program 
(238) is operative to control at least one of the in-home devices (150) by calling an 
Application Program Interface (API) (236) of the in-home application protocol 
(234/254); and the API emulator (236) is operative to provide a callable interface for 
functions of the in-home application protocol (234/254), and to supply this API 
functionality by communicating with the module (330) in the intermediate device 
(110) using the remote protocols (230/210) (page 6, lines 1 1-33). 

As broadly recited in claim 12, a method is provided for communicating in a 
communication system (100 - FIG. 3) including an in-home network (140 - FIGs. 3, 
4B) and a remote device (1 10 - FIGs. 3, 4B, 5) (page 4, lines 30-32). The in-home 
network (140) includes a plurality of in-home devices (150, 130 - FIGs. 3, 4B, 5) 
operative to communicate using predetermined in-home protocols (232/252; 234/254 
- FIG. 4B); including an in-home application protocol (234/254) (page 5, lines 12-13). 
At least one of the in-home devices is referred to as an intermediate device (130), 
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also being operative to communicate with the remote device (110) using 
predetermined remote protocols (230/210- FIG. 4B; 332/334 - FIG. 5) including a 
remote application protocol (332/334 - FIG. 5) which differs from the in-home 
application protocol (234/254) (page 6, lines 16-33). The method includes: (a) in the 
remote device (110), loading and executing a portable application program (238 - 
FIG. 4B) (page 6, lines 7-8) for controlling at least one of the in-home devices (150) 
by calling an Application Program Interface (API) (236) of the in-home application 
protocol (234/254); and (b) loading and executing an API emulator (310) operative to 
provide a callable interface for functions of the in-home application protocol 
(234/254), and to supply this API functionality by communicating with a module (330) 
in the intermediate device (130) using the remote protocols (page 6, lines 1 1-33); 
and (c) in the intermediate device (130), loading and executing: (1) an API (236) 
operative to provide interface functionality for the functions of the in-home application 
protocol (234/254) by controlling the intermediate device (130) and/or communicating 
with other in-home devices (150) according to application messages of the in-home 
application protocol (234/254) (page 5, line 32; page 7, lines 29-32; page 4, lines 24- 
29); and (2) the module (330) for communicating between the API emulator (310) in 
the remote device (110) and the API (236) in the intermediate device (130), 
establishing a substantially transparent communication path between the portable 
application program (238) in the remote device (110) and the API (236) in the 
intermediate device (130) (page 6, lines 18-33). 

GROUND OF REJECTION TO BE REVIEWED ON APPEAL 

The ground of rejection to be reviewed on Appeal is the rejection of claims 1- 
12 under 35 U.S.C. § 103 over Gibbs et al. U.S. Patent 6,169,725 ("Gibbs") in view 
of Zintel et al. U.S. Patent 6,547,066 ("Zintel"). 

ARGUMENTS 

Claims 1-12 Are All Patentable Over Gibbs in view of Zintel 

The FINAL Office Action dated 13 June 2006 rejects claims 1-12 under 35 
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U.S.C. § 103 over Gibbs in view of Zintel . 

Applicants respectfully traverse these rejections for at least the following 
reasons. 

Claim 1 

Among other things, the system of claim 1 includes an intermediate device 
including a module for communicating between an API emulator in a remote device 
and an API in the intermediate device using remote protocols , establishing a 
substantially transparent communication path between the portable application 
program in the remote device and the API in the intermediate device. Furthermore, 
claim 1 clearly recites that the remote application protocol differs from the in-home 
application protocol. 

The Office Action states at page 3, line 1 1 that Gibbs discloses such an 
intermediate device including a module for communicating between an API emulator 
in a remote device and an API in the intermediate device using remote protocols, 
establishing a substantially transparent communication path between the portable 
application program in the remote device and the API in the intermediate device, 
citing the 1394 Communication Media Manager (CMM) of Gibbs as supposedly 
corresponding to the recited module for communicating between an API emulator in 
a remote device and an API in the intermediate device using remote protocols. 

Applicants respectfully disagree. 

As its name indicates, the 1394 Communication Media Manager of Gibbs 
provides bus access to a 1394 bus. Gibbs shows the 1394 CMM in FIG. 5. Clearly, 
the 1394 CMM is for communicating between devices in the in-home network 
according to the in-home protocols l Indeed, at page 3, lines 1-2, the Examiner 
himself identified IEEE1394 as being the in-home protocol . 

For better understanding of the issue, the Board's attention is respectfully 
drawn to compare FIG. 5 in Gibbs with FIG. 1 of the present application also showing 
1394 CMM as element 50, and then to compare FIG. 5 in Gibbs with FIG. 4B of the 
present application, where the exemplary1394 CMMs for intermediate device 130 
and device 150 are labeled with reference numerals 232 and 252, respectively. Note 
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that in the embodiment of FIG. 4B of the present application, the module at issue 
here is element 330 in intermediate device 130, which actually provides 
communication between API emulator 310 in remote device 110 and API 236 in 
intermediate device 130 using TCP/IP remote protocols (i.e., remote protocols 
which differ from the in-home 1394 CMM protocols). 

Very clearly, Gibbs ' 1394 CMM does not and cannot provide communication 
between an API emulator in a remote device and an API in the intermediate device 
using remote protocols . 

So Applicants respectfully submit that no combination of Gibbs and Zintel 
could ever produce the system of claim 1 . 

Also among other things, the system of claim 1 includes a remote device 
operative to load an API emulator operative to provide a callable interface for 
functions of the in-home application protocol, and to supply this API functionality by 
communicating with a module in the intermediate device using remote protocols. 

The Examiner fairly admits that Gibbs fails to disclose or suggest any remote 
device including this combination of features. 

However, the Examiner maintains that Zintel teaches a "remotely control 
device" (sic) having all of these features, and that it would have been obvious to one 
of ordinary skill in the art at the time the invention was made to "apply the teaching of 
Zintel" to Gibb 's system "because the remote device is well-known as a remote 
control devices (sic) to be able to control other in-house network remotely, and since 
a module's role is a controller of other in-house devices, it is used to communicate 
with the remote device." 

At the outset, this statement is so grammatically flawed as to make its 
comprehension impossible without resorting to some amount of guesswork. 

Nevertheless, Applicants respectfully submit that no combination of the 
teachings of Gibbs and Zintel would have led anyone of ordinary skill in the art at the 
time the invention was made to have produced the system of claim 1 . In particular, 
neither Gibbs nor Zintel discloses a remote device operative to load an API emulator 
operative to provide a callable interface for functions of the in-home application 
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protocol, and to supply this API functionality by communicating with a module in the 
intermediate device using remote protocols 

As taught for example at page 1 , lines 7-8, and 17-20 of Applicants' 
specification, a remote device is "remote", and not an element of the in-home 
network, nor therefore is it equipped with the in-home protocols. This is consistent 
with the separate recitations in claim 1 of "an in-home network" and "a remote 
device." Claim 1 specifically recites that that the remote device communicates with 
a module in an intermediate device (which is part of the in-home network) using 
remote protocols "including a remote application protocol which differs from the 
in-home application protocol ." Thus, for example, as Applicants have disclosed, a 
remote device may communicate with a module in an intermediate device of an in- 
home network using remote protocols (e.g., via the Internet), while the in-home 
devices may communicate with each other using in-home protocols (e.g., HAVi 
protocols). Also as recited in claim 1 , the remote device is operative to load an API 
emulator of the in-home application protocol (e.g., an HAVi Java API emulator) so 
that it can provide a callable interface for functions of the in-home application 
protocol. For example, as taught at page 6, lines 12-20 of Applicants' specification: 

"Unlike the real HJA layer 236 as shown in Fig. 4A, the HJA emulator 
310 does not issue HAVi messages directly to a HAVi device. Instead, 
The HJA emulator 310 ensures that the interaction between itself and 
the Havlet 238 results in a same interaction with the real HJA 236, 
which actually provides the functionality. So, the HJA emulator 310 
'mimics' the HJA layer 236 by reporting the fact that HJA was called by 
the HAVi applet 238 and details about the call (like parameters) to the 
intermediate device 130. The intermediate device 130 is loaded with an 
additional module 330 which retrieves the information supplied to it by 
the HJA emulator 310 and issues the corresponding call to the HJA 
interface 236" 
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The Examiner does not cite any reference numeral of any element in any of 
the 50(!) figures of Zintel as supposedly corresponding to the remote device having 
the features of claim 1 . Instead, the Examiner very vaguely cites large portions of 
text from cols. 1,4,6,13 and 1 5 - without any explanation - as supposedly the 
remote device having the features of claim 1 . 

Applicants respectfully submit that nowhere in the cited text, or elsewhere, 
does Zintel disclose the remote device having the features of claim 1 . In that regard, 
Applicants note, for example, that FIG. 2 of Zintel, mentioned in the cited text, does 
not show any remote device as recited in claim 1 . For example, user control points 
104, 105 communicate with controlled devices 106 and 107 and bridged devices 122 
using UPnP protocols ( see e.g., col. 13, lines 1-4). 

Accordingly, for at least these additional reasons, Applicants respectfully 
submit that no combination of Gibbs and Zintel could ever produce the system of 
claim 1. 

Furthermore, Applicants respectfully traverse the proposed combination of 
Gibbs and Zintel as being improper. M.P.EP. § 2144.01 provides that: 

"Obviousness can only be established by combining or modifying the 
teachings of the prior art to produce the claimed invention where there 
is some teaching, suggestion, or motivation to do so found either 
explicitly or implicitly in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art." 

Here, the Examiner does not cite anything at all in support of its proposed 
motivation to modify Gibbs ' system to add a remote device having all of the features 
recited in claim 1 . A rejection under 35 U.S.C. § 103 must be based on objective 
evidence of record, and cannot be supported merely on subjective belief and 
unknown authority. M.P.E.P. § 2144.03 provides that: 

"there must be some form of evidence in the record to support an 



Atty. Docket No. NL000763 



Appl. No. 09/826,241 
Appeal Brief 



Page 11 of 19 



assertion of common knowledge. See In re Lee, 277 F.3d at 1344-45, 
61 USPQ2d at 1434-35 (Fed. Cir. 2002); In re Zurko, 258 F.3d at 
1386, 59 USPQ2d at 1697 (holding that general conclusions 
concerning what is "basic knowledge" or "common sense" to one of 
ordinary skill in the art without specific factual findings and some 
concrete evidence in the record to support these findings will not 
support an obviousness rejection)" 

(Emphasis added). See also In re Lee , 277 F.3d at 1343-44, 61 USPQ2d at 1433-34 
(Fed. Cir. 2002) (the examiner's finding of whether there is a teaching, motivation or 
suggestion to combine the teachings of the applied references must not be resolved 
based on "subjective belief and unknown authority," but must be "based on objective 
evidence of record."). 

No such concrete evidence has been provided by the Examiner here, nor did 
the Examiner submit an affidavit as required by 37 C.F.R. § 1.104(d)(2) if this 
proposed motive were based on facts within his personal knowledge ( see M.P.E.P. § 
2144.03). Applicants have previously requested such an affidavit if this rejection 
continued to be maintained based a motive for modification not explicitly suggested 
in the prior art, but no such affidavit was forthcoming from the Examiner. 

Accordingly, for at least these reasons, Applicants respectfully submit that 
claim 1 is patentable over the cited prior art. 

Claims 2-1 1 

Claims 2-1 1 depend from claim 1 and are therefore deemed to be patentable 
for at least the reasons set forth above with respect to claim 1 , and for the following 
additional reasons. 

Claim 8 

In the system of claim 8, the remote device is operative to load the 
portable application program and/or API emulator from an intermediate device. 

Applicants respectfully submit that no such feature is disclosed in any of the 
various portions of cited text in Zintel , Furthermore, the Examiner does not provide 
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any motivation that supposedly would have led one to modify Gibbs system to 
include a remote device operative to load the portable application program and/or 
API emulator from the intermediate device. Therefore, the proposed combination of 
Gibbs and Zintel with respect to claim 8 is traversed. 

Accordingly, for at least these additional reasons, Applicants respectfully 
submit that claim 8 is patentable over the cited prior art. 
Claim 9 

In the system of claim 9, the remote device is operative to load the 
portable application program and/or API emulator from an in-home device, other 
than an intermediate device, via the intermediate device. 

Applicants respectfully submit that no such feature is disclosed in any of the 
various portions of cited text in Zintel . Furthermore, the Examiner does not provide 
any motivation that supposedly would have led one to modify Gibbs system to 
include a remote device operative to load the portable application program and/or 
API emulator from the intermediate device. Therefore, the proposed combination of 
Gibbs and Zintel with respect to claim 9 is traversed. 

Accordingly, for at least these additional reasons, Applicants respectfully 
submit that claim 9 is patentable over the cited prior art. 

Claim 12 

Among other things, the method of claim 12 includes: (1) a remote device 
loading and executing an API emulator operative to provide a callable interface for 
functions of an in-home application protocol, and to supply this API functionality by 
communicating with a module in the intermediate device using the remote protocols; 
and (2) an intermediate device loading and executing a module for communicating 
between the API emulator in the remote device and an API in the intermediate 
device, establishing a substantially transparent communication path between a 
portable application program in the remote device and the API in the intermediate 
device. 

Applicants traverse the proposed combination of Gibbs and Zintel as being 
improper for the reasons explained above with respect to claim 1 . Furthermore, for 
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similar reasons to those set forth above with respect to claim 1 , Applicants 
respectfully submit that neither Gibbs nor Zintel discloses or suggests any such 
features, and therefore no possible combination of Gibbs and Zintel could ever 
produce the method of claim 12 including these features. 

Accordingly, for at least these additional reasons, Applicants respectfully 
submit that claim 12 is patentable over the cited prior art. 

CONCLUSION 

For all of the foregoing reasons, Applicants respectfully submits that claims 1- 
12 are all patentable over the cited prior art. Therefore, Applicants respectfully 
request that claims 1-12 be allowed and the application be passed to issue. 

If necessary, the Commissioner is hereby authorized in this, concurrent, and 
future replies to charge payment or credit any overpayment to Deposit Account No. 
50-0238 for any additional fees required under 37 C.F.R. § 1.16 or under 37 C.F.R. § 
1.17, particularly extension of time fees, and any fees under 37 C.F.R. § 41.20. 

Respectfully submitted, 

VOLENTINE FRANCOS & WHITT, P.L.L.C. 




Kenneth D. Springer 
Registration No. 39,843 



VOLENTINE FRANCOS & WHITT, P.L.L.C. 
11951 Freedom Drive, Suite 1260 
Reston, Virginia 20190 
Telephone No.: (571) 283-0724 
Facsimile No.: (571 ) 283-0740 
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CLAIMS APPENDIX 

1 . A communication system including an in-home network and a remote 
device; 

the in-home network including a plurality of in-home devices operative to 
communicate using predetermined in-home protocols including an in-home 
application protocol; at least one of the in-home devices, being referred to as 
intermediate device, also being operative to communicate with the remote device 
using predetermined remote protocols including a remote application protocol which 
differs from the in-home application protocol; 

the remote device being operative to load a portable application program for 
controlling at least one of the in-home devices by calling an Application Program 
Interface (API) of the in-home application protocol; and load an API emulator 
operative to provide a callable interface for functions of the in-home application 
protocol, and to supply this API functionality by communicating with a module in the 
intermediate device using the remote protocols; 

the intermediate device including: 

an API operative to provide interface functionality for the 
functions of the in-home application protocol by controlling the intermediate device 
an/or communicating with other in-home device(s) according to application 
messages of the in-home application protocol; and 

the module for communicating between the API emulator in the 
remote device and the API in the intermediate device, establishing a substantially 
transparent communication path between the portable application program in the 
remote device and the API in the intermediate device. 

2. A communication system as claimed in claim 1, wherein the in-home 
protocols include a messaging protocol, hierarchically below the in-home application 
protocol, and the API emulator being operative to supply the API functionality by 
executing the in-home application protocol in the remote device and supplying the in- 
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home application protocol an interface to the messaging protocol by communicating 
with the module in the intermediate device using the remote protocols. 

3. A communication system as claimed in claim 1 , wherein the in-home 
application protocols are Home Audio/Video interoperability (HAVi) based. 

4. A communication system as claimed in claim 1 , wherein the portable 
application program is Java based. 

5. A communication system as claimed in claim 1 , wherein the remote 
protocols are based on Internet protocols. 

6. A communication system as claimed in claim 1 , wherein the API emulator 
and the module communicate using a remote procedure calling protocol. 

7. A communication system as claimed in claim 1 , wherein information to be 
communicated between the API emulator and the module are described using a 
mark-up language. 

8. A communication system as claimed in claim 1 , wherein the remote device 
is operative to load the portable application program and/or API emulator from the 
intermediate device. 

9. A communication system as claimed in claim 8, wherein the remote device 
is operative to load the portable application program and/or API emulator from an in- 
home device, other than the intermediate device, via the intermediate device. 

10. A remote device for use in a communication system as claimed in claim 1 , 
the remote device being operative to load a portable application program for 
controlling an in-home device by calling an Application Program Interface (API) of an 
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in-home application protocol; and load an API emulator operative to provide a 
callable interface for functions of the in-home application protocol, and to supply this 
API functionality by communicating with a module in an intermediate device using 
predetermined remote protocols including a remote application protocol which differs 
from the in-home application protocol; the intermediate device being on an in-home 
network including a plurality of in-home devices operative to communicate using 
predetermined in-home protocols including the in-home application protocol. 

1 1 . An intermediate device for use in a communication system as claimed in 
claim 1, the intermediate device being on an in-home network including a plurality of 
in-home devices operative to communicate using predetermined in-home protocols 
including an in-home application protocol; the intermediate device also being 
operative to communicate with a remote device using predetermined remote 
protocols including a remote application protocol which differs from the in-home 
application protocol; the intermediate device including: 

an Application Program Interface (API) of the in-home application 
protocol operative to provide interface functionality for functions of the in-home 
application protocol by controlling the intermediate device an/or communicating with 
other in-home device(s) according to application messages of the in-home 
application protocol; and 

a module for communicating between an API emulator in the remote 
device and the API in the intermediate device, establishing a substantially 
transparent communication path between a portable application program in the 
remote device and the API in the intermediate device, where the portable application 
program is operative to control at least one of the in-home devices by calling an 
Application Program Interface (API) of the in-home application protocol; and the API 
emulator is operative to provide a callable interface for functions of the in-home 
application protocol, and to supply this API functionality by communicating with the 
module in the intermediate device using the remote protocols. 
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12. A method of communicating in a communication system including an in- 
home network and a remote device; the in-home network including a plurality of in- 
home devices operative to communicate using predetermined in-home protocols 
including an in-home application protocol; at least one of the in-home devices, being 
referred to as intermediate device, also being operative to communicate with the 
remote device using predetermined remote protocols including a remote application 
protocol which differs from the in-home application protocol; the method including: 

in the remote device, loading and executing a portable application program for 
controlling at least one of the in-home devices by calling an Application Program 
Interface (API) of the in-home application protocol; and loading and executing an API 
emulator operative to provide a callable interface for functions of the in-home 
application protocol, and to supply this API functionality by communicating with a 
module in the intermediate device using the remote protocols; and 
in the intermediate device, loading and executing: 

an API operative to provide interface functionality for the functions of 
the in-home application protocol by controlling the intermediate device an/or 
communicating with other in-home device(s) according to application messages of 
the in-home application protocol; and 

the module for communicating between the API emulator in the remote 
device and the API in the intermediate device, establishing a substantially 
transparent communication path between the portable application program in the 
remote device and the API in the intermediate device. 
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EVIDENCE APPENDIX 

{None} 
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RELATED PROCEEEDINGS APPENDIX 

{None} 
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